Most embedded and real-time control systems are designed according to a model in which interrupt handlers and software-managed tasks are each considered to be executing on their own “virtual” microcontroller. That model is generally supported by the services of a Real-Time Executive or Real-Time Operating System (RTOS), layered on top of the features and capabilities of the underlying machine architecture. The RTOS typically controls several concurrent operations. For example, the following operations can be controlled concurrently in a DVD optical drive: receiving and processing commands from a host computer; managing the flow of data to/from the media; positioning the pickup over the media (seeking); and managing the correction of data (error correction coding).
In an embedded environment, the processor is frequently “paused” while waiting for some hardware or software process to happen, such as waiting for a seek to finish or for a data block to be transferred. While the processor is paused with respect to a given task, it is desirable for the processor to switch to another task and attempt to advance that process, thereby gaining enhanced performance by performing more than one task in parallel.
In one example of DVD optical drive control, there are three switched firmware tasks, namely a host task, a disk task and a high level servo task, and one interrupt-driven task, namely a low level servo task. The disk task may want to start a seek operation and, while the seek operation is ongoing, the disk task can continue to process buffered data. The disk task can build a high level servo task command block with the desired seek location, and then release the processor so that it can switch to the high level servo task. When the high level servo task is activated and sees the new seek command, the high level servo task performs its required work, namely determining current and target locations and calculating the required track crossings for the low level servo to move the pickup. As soon as the high level servo task has set up the seek, it has nothing else to do until the low level servo task has completed the movement. Therefore, the high level servo task can release the processor so the processor can switch to another task (i.e. the disk task or the host task). Thus, in this example, the disk task is active concurrently with the seek operation. From time to time, the disk task can switch back to the high level servo task to see if the low level servo task has completed the seek operation. If it has not, the high level servo task can switch back to the disk task. This switching back and forth between the disk task and the high level servo task is completed relatively fast, so completion of the seek operation can still be recognized with good resolution, resulting in a negligible impact on the performance of the disk task.
Another example is when the disk task is performing an audio play operation (audio data from the media to the data buffer, audio data from the buffer to the digital-to-analog converter, and then to the headphone jack). During this audio play operation, the disk task can release the processor so it can switch to the host task, which can perform desired processing concurrently with the audio play operation and without interrupting the audio play operation.
There are various conventional approaches to task switching, including: operating systems based solely on interrupts; a task switching RTOS using a firmware-maintained stack (or multiple stacks) to save the context of each firmware task; a complex RTOS based on time-slice protocols (or other methods); and various task managers or state machines that can switch from one task to another. These aforementioned conventional approaches tend to be relatively complex, requiring undesirably large amounts of code space and execution time. These are critical factors for embedded software.
It is therefore desirable to provide for task switching that is less complex, and requires less code space and execution time than the conventional approaches.
According to the invention, a task switch from a first task to a second task can be accomplished by the first task calling a function which saves the first task's context, restores the second task's context, and then returns. Because the second task's context has been restored, the called function actually returns to the second task, thereby completing the task switch. This approach is advantageously simpler than the prior art approaches, and further advantageously requires less code space and less execution time than the prior art approaches.